Currently we have a tap event tracker that causes that every time a tap
happens in the lock screen, we reset the auth prompt and this can be
particularly annoying at least in three cases:
1. Just clicking everywhere in the screen may lead the unlock entry
content to be cleared
2. Clicking in the screen while an authentication is in progress,
cancels it
3. This may break a multi-factor authentication method, as a single
click may lead previous steps to be cancelled
So, while resetting the auth prompt is important when we're about to
show it, it's not something we want to do while an authentication has
started.
As per this also do not touch the auth prompt sensitivity unless we're
in an idle phase, or we may end up overriding the auth prompt state,
leading for example to a text entry being editable while we're verifying
the secret
Fixes: 37e55df29865dac13656116efdd7abec8056dea9
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3852>
(cherry picked from commit
962d1bf12f55bfadfc41eddd6eefb7597b9edde3)
import * as SwipeTracker from './swipeTracker.js';
import {formatDateWithCFormatString} from '../misc/dateUtils.js';
import * as AuthPrompt from '../gdm/authPrompt.js';
+import {AuthPromptStatus} from '../gdm/authPrompt.js';
// The timeout before going back automatically to the lock screen (in seconds)
const IDLE_TIMEOUT = 2 * 60;
this._promptBox.add_child(this._authPrompt);
}
- this._authPrompt.reset();
- this._authPrompt.updateSensitivity(true);
+ const {verificationStatus} = this._authPrompt;
+ switch (verificationStatus) {
+ case AuthPromptStatus.NOT_VERIFYING:
+ case AuthPromptStatus.VERIFICATION_CANCELLED:
+ case AuthPromptStatus.VERIFICATION_FAILED:
+ this._authPrompt.reset();
+ this._authPrompt.updateSensitivity(
+ verificationStatus === AuthPromptStatus.NOT_VERIFYING);
+ }
}
_maybeDestroyAuthPrompt() {